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1.0 INTRODUCTION 


A functional design for an Attached Payload Operations Center (APOC) has 
been prepared and is documented in Volume I of this report. The APOC was 
designed to support both Spacelab and non-Spacelab payloads. Early 
consideration was given to the support of the Office of Space Science (OSS) 
-3 thru 7 missions, which were renamed ASTRO following the transfer of 
mission management responsibility to the Marshall Space Flight Center 
(MSFC) . In addition, the requirements to support other attached payloads 
including several assigned Goddard Space Flight Center (GSFC) management 
responsibility were considered. These included the Solar Optical Telescope 
(SOT), OSS-2 (renamed Shuttle High Energy Astrophyslcal Laboratory (SHEAL)), 
Environmental Observation Mission (EOM) -A and Starlab. 

The APOC concept as designed capitalized on existing and planned GSFC 
facilities and the remote Payload Operations Control Center (POCC) 
capability currently being brought to operational status to support free- 
flyer launch and retrieval from the Space Transportation System (STS). 
This latter capability is provided by the Shuttle/POCC Interface Facility 
(SPIF). The SPIF provides a centralized capability for supporting specific 
STS management functions thereby avoiding the need to duplicate these 
capabilities for each POCC interfacing with the STS. The SPIF is the first 
remote POCC to be interfaced with the Johnson Space Center (JSC) Mission 
Control Center (MCC), which is responsible for the command of Orbiter flight 
and flight safety and resources management for the STS. Utilization of this 
facility within the APOC is significant since its capability will be 
demonstrated shortly in the support of two free-flyer programs in 1984. 
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The Multi-Satellite Operations Control Center (MSOCC) facility was also 
included as an integral part of the APOC functional design. This facility 
undergoes continual upgrade to maintain operational capability for the 
various f ree**£ lyers supported out of the GSFC. It provides a multi-mission 
POCC environment for support of up to six simultaneous missions plus soft- 
ware development. Utilization of this facility provides a proven operatio- 
nal environment and a lower APOC sustaining cost as a result of a distribu- 
tion of overhead functions. 

Channel two (2) and three (3) data from the Spacelab for payloads utilizing 
this European Space Agency (ESA) system are input via the Spacelab Data 
Processing Facility (SLDPF). This facility was developed to provide the 
necessary data processing functions and data product generation capability 
for data received from Spacelab payloads. The facility is configured with a 
Spacelab Input Processing System (SIPS) providing necessary data capture, 
demultiplexing, Data Quality Monitoring (DQM) and data accounting functions; 
and a Spacelab Output Processing System (SOPS) providing editing/formatting, 
time ordering and overlap removal, Input/output decommutation, ancillary 
processing, data accounting and data product generation. To support APOC 
additional SIPS capability was included to provide necessary capability for 
POCC functions. 

Various other GSFC insltitutlonal capabilities were utilized in the APOC 
design to provide required capability. These included the Flight Dynamics 
Facility (FDF) providing mission analysis and computational support, and 
operational and definitive attitude computation, the Command Management 
System (CMS) providing payload command management and a mission planning 
system providing the necessary tools and planning capability to support 
attached payloads with a link to the CMS. 
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2.0 APOC OVERVIEW 


An overview of the APOC is shewn in Figure 2-1. For Spaeelab payloads 
channel 2 and 3 data are input via a Statistical Multiplexer (SM) to the 
various SIPS functions. These Include recording of the data on High 
Density Recorders (HDR), DQM and demultiplexing of the composite data 
stream by the High Rate Demultiplexer (HRDM) . This system performs the 
inverse functions of the onboard Spaeelab High Rate Multiplexer (HRM) 
enabling access to the data streams as multiplexed onboard the Spaeelab. 
The contents and characteristics of channels one, two and three data as 
downlinked by the Tracking and Data Relay Satellite System (TDRSS) Ku-band 
are shown in Table 2-1. 

Channel one data is received by the MCC and processed with selected 
information provided to the APOC via the SPIF. This la received via the 
MSOCC switch. This includes Payload Data Interleaver (PDI) and Payload 
Parameter Frame (PPF) data from non-Spacelab payloads, which are input for 
processing by the SPIF or MSOCC as required. It should be noted that the 
SPIF is a separate facility, but utilizes several common systems 
capabilities with the MSOCC. 

Output data from the HRDM are synchronized and input to the MSOCC via the 
APOC switch. The HRDM output data streams are shown in Table 2-2. The 
APOC switch has the capability for switching data streams up to 10 Mbps. 
Higher rate streams ate patched on a mission-unique basis. Seve-n Frame 
Sync/Parameter Select (FS/PS) units are integral to the APOC switch and 
provide the capability to select subsets of required data streams. These 
streams can include selected experiment channels, the Experiment Computer 
Input/Output (ECIO) or Subsystems Computer Input/Output (SCIO) stream. 


2-1 



Figure 2—1. APOC Overview 














Table 2-1 

TDRSS Ku-Band Downlink for Spacelab 
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Tab £'3 2-2 

HRDM Output Data Streams 


Data Stream 

Number 

Bit Rate 

Experiment Channel 

16 

200 bps up to 16 Mbps 

High Data Rate Recorder ( HDRR) 

1 

2/4/8/12/ 16/24/32 Mbps 

Payload Recorder (PR) 

1 

1 Mbps 

Experiment Computer 
Input/ Output 

1 

200 bps up to 0.5 Mbps-* - 

Subsystem Computer 
Input/Output 

1 

200 bps up to 0.5 Mbps* 

GMT 

1 

Retrieved from downlink 
stati s words 


1 Maximum Input Rate 25.6 Kbps 
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Data streams may be input for processing by an Applications Processor (AP) 
or provided to a user room for processing by experimenter provided 
Electrical Ground Support Equipment (EGSE). The AP could typically provide 
simple processing such as limit checking of engineering data contained 
within the ECIO or arithmetic operations on a subset of an experiment 
channel to support an instrument monitoring function. In general proces- 
sing of scientific data to support quicklook analysis would be provided by 
the EGSE. A maximum of 2000 parameters per second (16-bits per parameter) 
may be input to the AP for processing, although this capability is planned 
to be increased to 4000 parameters per second in January, 1986. A Near- 
Realtime (NRT) capability is provided, whereby STS and payload parameters 
are stored for on-demand access on a shared basis. This system has the 
capability to store 500 STS parameters per second (extracted from the STS 
data contained within Channel one and transferred from the MCC) and up to 
9200 payload parameters, where these latter parameters are extracted from 
the various data streams and subsets provided from the AP0C switch and/or 
the PDI and PPF. 

Output of the results of the processing within the AP are transferred via a 
Virtual Interface Processor (VIP) to various peripherals contained within 
the Payload Control Rooms (PCR) and/or Payload Support Rooms (PSR) as 
required. These include terminal devices consisting of a Personal Computer 
(PC) with floppy disk and dot matrix printer, and/or a Strip Chart Recorder 
(SCR). Forty PC terminal systems are included in the APOC upgrade of the 
MSOCC facility, and a total of seven SCRs will be made available. 

Commands may be input via the terminal devices and transferred to the AP 
for processing and uplink via the MCC. Other command modes supported 
include direct transfer of commands from EGSE to the AP and/or transfer 


from a remote location to the AP. Command types include , realtime: time 
tagged, discrete (on/:;ff), group, procedure, restricted and critical j and 
preprogrammed; command memory load, Dedicated Experiment Processor (DEP) 
and microprocessor loads, and Experiment Computer Operating System (ECOS) 
and/or Experiment Computer Applications System (ECAS) loads/ updates. 

The APOC hardware and software processing resources are configured by the 
Data Operations Control System (DOCS), This system has the necessary 
switching and control capability to meet APOC scheduling requirements and 
configuration of required telemetry and command data formats. In addition 
the Data Operations Control (DOC) area has communications links (data 
lines, SCAMA [switching, conferencing, and monitoring arrangement], CCL 
[closed-conference loops] and PBX [private- business exchange] telephone) to 
establish interfaces with other support facilities as required. 
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3,0 DMA FLOW 


nr 


A detailed block diagram for the APOC functional design is shown in Figure 
3—1 • This diagram shows four SIPS processing lines. SIPS A&B are the 
present SIPS capability Included within the SLDPF, SIPS C is a proposed 
augmentation of the SLDPF to provide capability to support the APOC 
operational requirements. SIPS D is a planned augmentation to provide 
additional SIPS capability to meet the increased SLDPF processing 
requirements of the projected flight manifest, SIPS C&D as proposed 
utilize the proven design of the current processing lines. The only 
difference being a reduction of the number of HDRs from 5 to 2 for the C 
and D processing lines. This reduced number was determined to be adequate 
to support the APOC operational requirements for data recording and play- 
back, The SIPS A&B processing lines provide the NASA wide capability for 
Spacel**'* alsslon support and also support the SOPS. 

The layout of the MSOCC including the MSOCC switch, Telemetry and Command 
(TAC) , Recorder/Utility Processor/ Simulator (RUPS) and AP units utilizes 
the current MSOCC system with planned upgrades. These Include the AP, TAC 
and DOC processor upgrades shown in Table 3-1 and a local Area Network 
(LAN) and VIP switching capability. These upgrades are planned to maintain 
required capability to support future free-flyer spacecraft. The VIP is 
shown communicating to various terminal devices within the PCRs, PSRs, 
Mission Support Room (MSR) and/or user rooms. The layout of these rooms 
and the terminology correspond to a revised floor plan for the APOC within 
building 14 at the GSFC. Figure 3-2 shows the revised floor plan for the 
second floor, The noticeable difference from the current configuration is 
the inclusion of two PCRs for APOC support. With this layout inclusion of 
the adjacent Mission Operations Room (MOR) with the PCR may be undertaker 
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Figure 3-1. GSFC Attached Payload Operations Center (APOC) Block DiagiMFC 
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Table 3-1 

Planned MSGCC Upgrades 
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to provide increased operational space when required. Figure 3-3 shows the 
revised floor plan for the building 14 ground floor. An area is Included 
for user space where EGSE will be configured for operational support. This 
user space may be configured into separate user rooms or areas as required 
to meet mission-unique requirements. An adjacent MSR area is included to 
provide office and conference space for the experimenters , Table 3-2 
provides details of the floor space provided by this layout. 

The APOC switch which is controlled from the DOCS was designed specifically 
to meet APOC requirements. This switch provides capability to switch 
specific incoming Spacelab data streams and also parameter select of 
specific subsets from up to seven data streams according to mission 
requirements. The maximum data stream rate which can be handled is 10 
Mbps. Data streams of higher rate must be connected via patch panel 
capability. 

The data flows within various parts of the APOC functional design are 
described in more detail in the following sub-sections. 


3.1 SIPS. 


The data flows to the HDTs, DQM and HRDMs are described in this subsection, 
a) HDT 

The SIPS provides recording of incoming channel 2 and 3 data on HDTs. 
The characteristics of the HDTs are presented in Table 3-3. The data 
streams are input to the HDTs via an HDT input switch. This system is 
essentially a patch panel. To ensure that the data are properly captured a 
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Table 3-2 

Facility Floor Space (Sq. Ft. 
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2600 2090 


Table 3-3 

HDT Characteristics 


Parameter 


Value 


Tape length - total 

- usable (minus leading/ 
trailing) 


9200 feet 
8543 feet 


Density 

Gross Capacity 

Useful Capacity (minus bits for 

synchronization and cyclic redundancy 
check) 

Capacity [80 percent] 


29 kbpi [kilobits per inch] 
with 22 tracks fan-out 
65,405 Mbits 
59,459 Mbits or 
7,400 Mbytes 

5920 Mbytes 


Recording time supported 
At 32 Mbps 


31 minutes [full] 

25 minutes [80 percent] 


At 48 Mbps 


21 minutes [full] 

16 minutes [80 percent] 


Time to rewind 


6 minutes 
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Frame Synchronizer Unit (FSU) is used with each HOT to monitor the 
quality of the data recorded. 

The configuration utilized for both the SIPS A&B and SIPS C&D systems 
is a function of the operational requirements and input data rates of 
channel 2 and 3 utilized. With reference to Table 3-3, it can be seen 
that an HDT will support approximately 16-30 minutes depending on mode. 

In general, an HDT is started 3 minutes before the scheduled start of a 
transmission. 

Various operational configurations have been developed for the HDT 
system. In general, proper operation is validated via monitoring of 
the FSU outputs by the appropriate Systems Engineering Laboratories 
(SEL) 32/7780 computer. For instance, if it was initially planned to 
record on HDT 1 on SIPS C&D, with changeover on to HDT 2 after 20 
minutes for continuation purposes, then the HDT input switch would be 
patched accordingly. Following completion of this manual patch, the 
sequence would be performed in realtime under the control of the SEL. 
Providing all FSU outputs were normal the sequence would be completed 
properly. If the FSU for HDT 1 initially indicated an error, the 
system would transfer over to HDT 2 early, thereby ensuring data 
recording. In general, whenever the HDT availability changes, a message 
is provided by the SEL to an operator to take appropriate action. This 
could include patching an alternate HDT or changing the planned 
sequence. A feature is available to enable the FSUs to be monitored 
manually during periods, when the SEL is not available. 

The SIPS system provides a number of FSUs for monitoring the HDTs and 
HRDMs. For SIPS A & B 23 FSUs are available within each Frame 
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Synchronizer Subsystem (FPS) (FSS A & 8] . Eighteen of these are 
experiment FSUs and five monitor FSUs. Any monitor FSU may be selected 
by the operator to monitor the data quality recorded on any HDT via an 
HRDM and FSU input switch. 

b) DQM 


The SIPS monitors and reports the quality of all data received as a 
standard SLDPF function. Data streams reported on for data quality 
include the composite input data stream, the demultiplexed individual 
data streams following processing by an HRDM, and the Direct Access 
Channel (DAC). A number of devices are involved in the gathering of 
DQM statistics for the SIPS including the SEL, HRDM and FSU input 
switch, FSS, HRDM and the disk subsystem. The HDT input switch and 
HDTs are also required when processing data for DQM reporting post- 
transmission. 

The composite data quality is monitored by the FSUs. The demultiplexed 
data streams output from the HRDM are monitored by eighteen experiment 
FSUs. The DAC data stream is monitored by a monitor FSU in realtime 
and directly by a monitor FSU during playback. The FSUs can be 
operated in a data mode or a monitor-only mode during DQM. During the 
data mode, the FSU transfers a block of data via a Fast Data Interface 
(FDI) to a designated buffer area and also transfers a status report 
concerning data quality when the buffer is full. The output of the 
buffer are transferred to an output tape by the SEL computer. The 
input data are triple-buffered to allow output tape error recovery. In 
the monitor-only mode, the FSU transfers a status report to the SEL 


computer upon request. The history of all DQM statistics collected by 
the FSUs is stored for DQM report generation by the SEL. 

Data quality Information is sampled from each FSU once every 60 seconds 
and at Acquisition of Signal (AOS) and Loss of Signal (LOS) of a 
transmission. The DQM information is used to determine proper SLDPF 
operation and to support DQM reporting to the JSC, These latter 
reports are provided on JSC request. Information collected with each 
data quality sample includes: 


1) 

sample time 



il) 

device functional assignment 


iii) 

device status 



iv) 

count of frames 



v) 

loss of lock count 



vii) 

missing sync count 



vii) 

count of frames with 

sync bit error 


viii) 

count of frames with 

sync bit error 

and bit slip 

ix) 

count of frames with 

bit slip 


x) 

count of frames with suspected time 

tag. 


c) HRDM 

Each SIPs system [A & B and C & D] has an HRDM and FSS input switch, 
which can route the channel 2 and 3 composite streams or the playback 
from the HDTs to both the HRDM and the FSS. Both systems have two each 
of these latter units to provide redundancy. Each FSS has eighteen 
FSUs which are used for receiving demultiplexed data from HRDMs. SIPS 
A & B has five remaining FSUs (monitoring FSUs) connected directly to 
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the output of the HRDM and FSU input switch. These are used for 
monitoring the data quality recorded by the KDTs, SIPS C & D has only 
2 HDTs and therefore only requires 2 monitor FSUs on each FSS, however 
five may be included for consistency with the current SIPS A & B 
system. 

The HRDMs demultiplex the composite input stream into the data streams 
shown in Table 2-1. HDRR and PR data are recorded on HDTs for subse- 
quent playback as required. The double demultiplexing of the data is 
removed on the second transit through the HRDMs. Minor frame synchroni- 
zation of individual data streams, formatting, data-quality flagging, 
and time tagging of minor frames as well as frame and data-flag count- 
ing is performed by experiment FSUs, Each of the sixteen experiment 
channel FSUs within each FSS is uniquely intsbifonnected with one of 16 
FDI units contained within its corresponding experiment channel Fast 
Multiplexer System (FMS). Each of the other seven FSUs of each FSS 
(SIPS A & B) is uniquely connected with one of seven FDIs contained 
within a corresponding master FMS. 

The experiment channel FMSs and the master FMSs are connected to the 
SEL 32/7780 computer in such a way that either master FMS for SIPS A & 
B can be accessed by SEL A or B, but each experiment channel FMS can 
only be accessed by the corresponding SEL computer. A similar arrange- 
ment is proposed for SIPS C & D. 

d) SEL 32/7780 Computers 

Each SEL computer system is a dual processor processing unit consisting 
of a Central Processing Unit (CPU) and an Internal Processing Unit 


(IPU). Two private disks are provided for each Bystera, and two shared 
disks are provided that are accessible by each computer system and are 
used to store SIPS software, mission-related files, and a data base. 
The contents of these latter two disks are identical and data are 
written to both disks simultaneously. This applies to both SIPS A & B 
and C & D and therefore a single point failure is avoided. 

3.2 APOC Switch 

The APOC switch has been designed to distribute HRDM output data to an AP 
within the MSOCC, EGSE within the user area, and /or remote users from the 
GSFC. These data include the sixteen experiment channels, the ECIO and 
SCIO. Ihe switch can handle data streams with data rates less than 10 
Mbps, Higher rate streams must be connected via a patch panel type 
capability, The APOC switch provides the capability to select a subset of 
data from a given stream with the use of a FS/PS. Following extraction of 
the subset the resultant data can be distributed as before to an AP, EGSE 
and/or remote. Seven FS/PS units are planned for the APOC functional 
design, although the APOC switch design approach is modular and therefore 
additional units could be added as needed. 

The APOC switch was designed to meet or exceed the Spacelab POCC functional 
requirements as Initially provided to JSC for the JSC POCC and subsequently 
as modified by the MSFC. These requirements specified the need for a 
capability to extract from up to four streams a total of 2000 parameters a 
second for processing. A maximum of 9200 parameters a second could be 
extracted and provided to the NRT on-line data base for on-demand access. 
The maximum data stream input rate for subset extraction was 2 Mbps, 


although this value was reduced by the MSFC to a maximum of 2 Mbps for 
three streams. 

The subsets to be extracted from a given stream would normally be 
determined pre-mission and stored in a data base. During the mission the 
required format would be select? 1 and used to configure the FS/PS 
accordingly. Other configuration information stored in the data base pre- 
mission includes the data stream switch connections and frame sync 
parameters. Hie APQC switch is contolled by two microcomputer based 
controllers, which report to the DOCS. The configuration data base resides 
on these controllers. A design requirement is that the switch can respond 
to a configuration and/or format change command is less than five seconds. 

The DOCS controls the APOC switch configuration according to the 
requirements specified pre-mission or cs modified during operational sup- 
port. New configuration identifiers are transferred to the controller, 
which retrieve the required parameters from the configuration data base. 
The switch configuration and data quality status are reported back to the 
DOCS. 

3.3 MSOCC Switch 

STS ancillary and non-Spacelab data are input via the MSOCC switch. These 
data include Orbiter ancillary datr,, PDI and PPF extracted from the Opera- 
tional Downlink (OD) on Channel 1; Orbiter epheraeris including trajectory, 
tracking data and Orbiter' attitude information; and JSC status, Command 
Acceptance Patterns (CAP) generated in response to GSFC transmitted payload 
commands and command history information. These data are normally provided 
to the SPIF, but may be provided to other MSOCC systems as required. The 
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GSFC generated payload commands are transmitted to the MCC via the MSOCC 
switch. Other information available to the APOC via the SPIF interface 
include crew activity plans from the Crew Activity Planning System (CAPS), 
Orbiter voice and video and communications with the MCC via data facsimile 
and teletype. The SPIF also provides a Text and Graphics (TAGS) system for 
uplink facsimile type capability to the Orbiter crew. 

Orbiter tracking data are received by the SPIF every three minutes under 
timeline control or by request. These data are provided to the FDF and 
processed to provide Closed Circuit Television (CCTV) displays for users 
within the MSOCC or user EGSE area. Two-hour projections ate available 
containing all planned Orbiter maneuvers. Orbiter attitude data is 
received every twelve seconds under timeline control or by request. These 
data are provided to the FDF and formatted for user CCTV display. 
Projections covering the next forty-eight hours are provided. 

Auditing of MSOCC generated payload commands transmitted via the MSOCC 
switch is provided by the SPIF. This audit ensures the APOC-to-payload 
command interface validity via receipt, identification and validation of 
MSOCC command blocks and decode and verification of responding MCC CAPs. A 
log of command validation and CAP processing results is maintained in the 
SPIF command data base. Command performance reports may be prepared from 
this d,.ta base and formatted for hardcopy and CCTV display for users. JSC 
realtime and off-line command history data are also received by the SPIF 
and formatted for hardcopy and CCTV display. 

Payload telemetry data received by the SPIF via the MSOCC switch is 
validated for proper NASA Communications (NASCOM) header, user header and 
block error control fields to ensure proper block sequence and non-presence 
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of missing blocks and transmission errors, PDI and PPF data extracted from 
the OD may be processed, converted to engineering data and diplayed. In 
addition, STS ancillary data extracted from the OD and transferred to the 
SPIF may be processed to provide user CCTV displays. The received JSC 
status blocks containing Operational Instrumentation (01) and PDI data 
quality and routing information may also be processed by the SPIF to 
provide user CCTV displays. 

Several testing and simulations functions validating the MSOCC switch 
interface to the MCC are also provided by the SPIF. These include 
coordination scheduling and support of MSOCC/MCC interface testing, 
monitoring of the MSOCC/MCC interface during pre-nission testing and flight 
operations and simulation of the MCC communications interface for APOC 
checkout. Data flow fault analyses may be conducted to report monitored 
information. These are conducted following error recognition. 

The TAC subsystems support preprocessing both of telemetry and command data 
going to and from selected APs and the NASCOM lines via the MSOCC switch. 
These subsystems provide a flexible routing capability for incoming data. 
In addition to bounding the frame sync, the TAC may perform polynomial 
error checking and has a complete set of routing parameters that allow 
definition of the type'of data to be passed to an AP. Tolerance on bit 
errors in the sync patterns can be set to allows restrictive or general 
passing of data of questionable quality. The TAC system also performs 
output format and labelling of MSOCC-transmitted commands and acknowledge- 
ments. NASCOM line monitoring and recording functions for all data enter- 
ing and for scheduled data leaving the MSOCC may be provided by the RUPS 
subsystems. These subsystems produce an inventory record of all data 
blocks and a history tape of all data received in the MSOCC. 
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3.4 AP 


Selected data may be provided to the APs for various types of processing. 
These include ECIO, SCIO and/or experiment channel data or subsets 
extracted by the APOC switch and transferred via the AP data mux, STS 
ancillary data, and PDI and PPF data. In addition, the APs provide various 
command processing functions. The processing conducted includes telemetry 
processing, command generation, display page generation, history tape 
generation, command verification and telemetry limit checking. 

The APs provide extensive standard command and telemetry functions, which 
may be readily augmented with mission-unique software as required. This 
capability has been proven in the support of many free-flyer programs 
within the MSOCC multi-mission environment. The various standard functions 
may be simply tailored to meet defined mission requirements via input of 
appropriate data base information. This concept is used extensively within 
the MSOCC. 

An NRT data archival capability consisting of a 1.2 GB disk system has been 
added to support the APOC. This system was sized to provide on-line 
storage and access for the 500 STS parameters and 9200 payload parameters 
received over a twenty-four hour period. The system provides on-demand 
access on a shared basis for recall and processing of telemetry and history 
data. Processing is provided via access to the standard APOC realtime 
processing capabilities. Output utilizes the APOC terminals and associated 
peripherals . 
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3.5 Operational and Support Rooms 


As described in Section 3.0, the various MSOCC facilities have been 
redesigned and upgraded in the APOC functional design. Two PCRs, two PSRs, 
an MSR and a user EGSE area are provided. These areas are equipped with 
upgraded consoles and terminal capabilities including 40 PC systems with 
associated peripherals. The VIP network interfaces these capabilities with 
the overall APOC system. The VIP network allows a device-independent 
interface from the APs, DOCS and APOC switch to the various displays, 
printers, graphics terminals, SCRs and other special peripherals. 

3.6 Access 

The access to the various data types within the APOC are summarized below. 

a) Realtime 

Realtime channel 2 and 3 data from Spacelab are input through the SIPS 
C & D system via the APOC switch to appropriate APs and/or user EGSE. 
These data include the ECIO, SCIO, experiment channel data and/or 
subsets and GMT. Non-Spacelab data, STS ancillary and various JSC 
planning, operational and history data are received via the MSOCC and 
SPIF. Payload commands generated within the CMS or MSOCC are 

transmitted to the MCC via the MSOCC switch. 

b) NRT 

Data may be accessed in non-realtime via the NRT system. This system 
stores the 500 S’ ’S parameters and 9200 payload parameters for 
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subsequent recall and processing. In addition, the Spaceiab channel 2 
and 3 composite streams may be accessed from the SIPS HDTs, 
demultiplexed within the redundant HRDM and processed via the standard 
APOC realtime capabilities and/or i’GSE on a shared basis. Other 
history data may be accessed from the SPIF and MSOCC data bases. 

c) HDRR and PR 

HDRR and PR data within the incoming Spaceiab composite stream have 
been multiplexed on-board twice by tho HRM. On processing by the HRDMs 
in realtime or on playback from an HDT the data are demultiplexed once. 
The singly multiplexed data streams from the HRDM output are recorded 
on the HDTs. On subsequent playback from the HDT through the HRDM the 
demultiplexed HDRR and PR data are obtained. These data may be 
processed through the standard APOC processing capability on a shared 
basis. 

d) Commands 

Commands originating from an APOC terminal, the CMS, EGSE or remote are 
input to an AP for processing prior to transfer to the JSC MCC via the 
MSOCC switch. 
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4.0 TIMELINE CONTROL 


The current SLDPF is configured for mission support based on a timeline 
generated by the center assigned mission management responsibility. This 
timeline is supplied in the form of a Computer Compatible Tape (CCT) for 
input to the SLDPF system. The MSOCC and SPIF are controlled by the DOCS. 
In developing the APOC concept these control modes were retained. In the 
case of GSFC assigned missions the, SLDPF timeline information would be 
generated by the mission planning system. The DOCS would also configure 
the remainder of the APOC based on timeline data obtained from the mission 
planning system. The APOC switch was placed under the control of the DOCS. 

4.1 SIPS 

Three types of timelines are used to satisfy the SIPS requirements: 

o Premission timeline 
o Operational timeline 
o As-flown timeline. 

The premission timeline defines all experiments to be processed by the SIPS 
during each mission and is developed and delivered to the SLDPF prior to 
launch. The operational timeline consists of updates to the premission 
timeline. It is provided at periodic intervals of approximately twelve 
hours, prior to specific upcoming 12-hour mission segments. Currently 
these updates are provided by the JSC Payload Data Manager. The as-flown 
timeline consists of annotated versions of the operational timeline. It is 
the final record of actual experiment activity, including exceptions to 
preplanned data contained in either the operational or premission 
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timelines. The as-*flown timelines are currently provided by the JSC Pay- 
load Data Manager at periodic intervals of twelve hours and record the 
actual activity during the immediately preceding 12-hour period. 

a) Premission Timeline 

There are two types of Premission Timeline Tape (PTT); a downlink configu- 
ration. PTT and an Experiment/ TDRS PTT. The downlink configuration PTT 
contains the date of tape creation, a single header record, and one or more 
HRM format and downlink schedule records. The HRM format and downlink 
schedule record defines a unique HRM format and the associated start and 
stop times. One of these records exists for every unique period during the 
mission during which the Ku-band channel configuration does not change and 
within this configuration, the HRM format does not change. 

The experiment/ TDRS PTT contains the date of tape creation, a single 
header record and one or mom of each of experiment on-off records and 
TDRS records. The experiment on-off record appears once for every 
start-stop operation of an experiment (format change or rate change) 
and defines the start and stop times and associated experiment/format 
identifiers. The TDRS record appears once for every TDRS contact/sup- 
port period and defines the start and stop times and associated TDRS 
characteristics . 

b) Operational Timeline 

Updates to the premission timeline are provided by the JSC Payload Data 
Manager via facsimile and voice link. 
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c) As-flown Timeline 


T 
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The as-flown timeline consisting of annotated versions of the opera- 
tional timeline are transmitted by facsimile by the JSC Payload Data 
Manager. In general, only pages reflecting actual changes or 
optionally a small number of changes within a single datafax 
transmission are provided 

d) Operational Usage 

The premission timeline is processed by the SIPS to define the patch 
panel configurations needed to support the mission. Providing these 
patch panel configurations are manually performed in proper sequence, 
the SIPS can support the mission under the control of the SEL according 
to the timeline. In instances where a patch panel connection is 
incorrect or there is an equipment malfunction or loss of recording 
various operator managers are provided by the system. For instance, in 
cases of improper HDT recording, the continuation tape could be put in 
operation early as described previously. In general, operator interac - 
tion Is required to repatch various switches, configure redundant 
systems or change various configuration data within the SEL depending 
on the problem in question,; 

When changes to the premission timeline are received in the form of 
operational timeline updates an update timeline data base is generated 
by merging the appropriate data. In all cases, this updated timeline 
data base which consists of the downlink configuration PTT and 
experiment/ TDRS PTT information is validated prior to use. 
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The various formats capable of being demultiplexed by the HRDMs are 
defined pre-mission. Sixteen formats are resident and 6 A are available 
within an HRDM. The appropriate format is selected by the SEL during 
the mission via its corresponding identifiers. 

The SIPS has an automated test mode for problem resolution. This mode, 
the SIPS Automated Test System (SIPSATS) supports many SIPS functions, 
but does not provide the standard data qulaity accounting. 

4.2 DOCS 

Various hardware and software upgrades to the DOCS are planned as part of 
current MSOCC developments. These upgrades are designed to implement an 
automated DOCS capable of configuring and monitoring the MSOCC resources. 
These upgrades will be available to support APOC. The upgrades include 
automatic allocation of MSOCC resources, monitoring of MSOCC host computers 
attached to the LAN, internal (and in some cases external) configuration 
control of the LAN host computers, monitoring and control of the automated 
MSOCC switches, providing the System Test Operations Language (STOL) for 
operator control, AP downline loading capability, inclusion of Mission 
Planning Terminal (MPT) schedule interfaces, DOC display enhancements, STOL 
procedural capability, history event recording, AP history recording and 
playback capabilities, error detection and fault isolation capabilities 
within MSOCC and Increased operational manageability. 


5.0 OPERATIONS PERSONNEL 


The APOC operations management structure was configured to support all APOC 
operational requirements, provide required interfaces to the standard JSC 
operations structure and provide the necessary environment for the 
investigators for payload operations. The APOC operations management 
structure is shown in figure 5-1. Several features of this management 
structure are significant Including. 

o The presence of a GSFC Payload Operations Coordinator at the JSC to 
enhance payload operations coordination. The Payload Operations 
Coordinator interfaces with the JSC Payload Officer and reports to 
the GSFC Payload Operations Director. The Payload Operations 
Coordinator is familiar with GSFC payload operations requirements 
and practices and provides face-to-face contact with JSC payload 
operations personnel as required thus minimizing any problems 
associated with remote POCC operations. 

o A Crew Interface Coordinator at the APOC providing coordination of 
all crew/ APOC communications and interfacing with the JSC CAPCOM, 

o A Data Management Coordinator coordinating with the JSC INCO and 
the Payload Data Manager and ensuring that the various APOC systems 
are configured for proper operational support of incoming data 
streams. 
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o A Payload Activity Planner coordinating all premiesion payload 
planning and operational payload plan updates. This individual 
interfaces with the JSC FIDO and Flight Activity Officer (FAO) 

o The Mission Scientist interfacing directly with the GSFC Mission 
Operations Manager (MOM). The mission scientist has responsibility 
for providing coordination of Principal Investigator (PI) 
requirements . 

o Pis and their staff responsible directly for the formulation of 
payload planning inputs and payload operations. Operational 
support would be provided out of the user EGSE area. 


